Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix RemoteExecutor for VS testhost #7426

Merged
merged 8 commits into from
May 24, 2021

Conversation

antonfirsov
Copy link
Member

@antonfirsov antonfirsov commented May 21, 2021

Description

Address #6371 for cases when VS testhost is the runner. The fix is Windows-specific.

/cc @vitek-karas @ViktorHofer @JimBobSquarePants @RussKie

To double check:

The validation process above looks very complicated, I have no opportunity to go through it. Note that the change enables disabled tests. I did a local run with both Visual Studio and dotnet test.

Path = typeof(RemoteExecutor).Assembly.Location;

if (IsNetCore())
{
HostRunner = processFileName;

// Running with an apphost, eg. Visual Studio testhost. We should attempt to find and use dotnet.exe.
// This is a Windows-only workaround.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the only Windows-specific part of the workaround the .exe suffix? Can we look for dotnet.exe on Windows and dotnet everywhere else?

Copy link
Member Author

@antonfirsov antonfirsov May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no time / opportunity to validate the change with Unix test hosts, therefore I'm keeping this fix scoped to Windows + VS testhost intentionally. I don't want to add general code I cannot test.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you keep this Windows only, do you also need to re-enable the tests on Windows only and keep them disabled on non-Windows? I do not think it is worth the troubles.

The Windows specific logic is very minimal. I would be ok with adding it without you explicitly validating it. Add string hostName = RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? "dotnet.exe" : dotnet"; and use it throughout the change instead of hardcoding dotnet.exe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in fb32b03.

@@ -10,6 +10,7 @@
using System.Runtime.InteropServices;
using System.Threading.Tasks;
using Xunit;
using IOPath = System.IO.Path;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just use using System.IO; and Path?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RemoteExecutor has a field named Path.

@ViktorHofer
Copy link
Member

ViktorHofer commented May 21, 2021

The validation process above looks very complicated, I have no opportunity to go through it. Note that the change enables disabled tests. I did a local run with both Visual Studio and dotnet test.

Tbh I don't think that validation process makes much sense. What would be very useful to test is the integration in dotnet/runtime. Can you please push the locally built RemoteExecutor package to any feed so that we can then submit a PR in dotnet/runtime to consume and test it? (by adding the feed into the NuGet.config file and updating the version in Versions.props)

If you don't have a feed handy let me know and I can push it to mine (myget which is free).

I doubt that this would break dotnet/runtime's usage of RemoteExecutor but better check before merging...

antonfirsov added a commit to antonfirsov/runtime that referenced this pull request May 22, 2021
@antonfirsov
Copy link
Member Author

I did the validation as requested. All tests passed in dotnet/runtime#53125, hopefully not as false positives 😄

Co-authored-by: Igor Velikorossov <RussKie@users.noreply.github.com>
@ViktorHofer ViktorHofer merged commit 91b1357 into dotnet:main May 24, 2021
@ViktorHofer
Copy link
Member

Thanks a lot for the valuable contribution @antonfirsov 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants